N91 -10944 


HUMAN-CENTERED AUTOMATION: 
DEVELOPMENT OF A PHILOSOPHY 


Curtis Graeber 
and 

Charles E. Billings 
NASA Ames Research Center 


91 



AVIATION SAFETY/AUTOMATION PROGRAM CONFERENCE 

11 -12 October 1989 

HUMAN-CENTERED AUTOMATION PHILOSOPHY 


ATA National Plan, April 1989; pg. 5: 

• The fundamental concern is the lack of a scientifically based philosophy of 
automation which describes the circumstances under which tasks are 
appropriately allocated to the machine and/or to the pilot. 

- Humans will continue to manage and direct the NAS through 2010. 

- Automation should be designed to assist and augment the capabilities of 
the human managers. 

- It is vitally important to develop human-centered automation for the 
piloted cockpit and controller work station. 

• NASA's Aviation Safety/Automation Program is founded in large part on these precepts. 


IMPLICATIONS OF THE PRECEPTS IN THE NATIONAL PLAN 


• An explicit philosophy of automation, and the explicit allocation of functions between 
humans and machines in the system, are inextricable. 

- Both must be approached as fundamental design issues. 

• By implication, automation can be designed to fulfill any task necessary for effective 
system functioning. 

- This is not true yet, but we believe it will be within a decade or so, perhaps 
sooner. 

• Despite this automation capability, humans are to continue to manage and control 
the system, for a variety of social and political as well as technical (and probably 
economic) reasons. 

- Automation should therefore function to supplement, not to supplant, the 
human management and control function in civil air transport. 
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Automation implementation to date has been largely technology-driven 
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Do these systems, as implemented to date, supplement, or tend to 
supplant, the flight crew as manager and controller of its aircraft? 

Do they perform the functions that a human-centered automation 
philosophy would allocate to the machine, or to the human? 


• To answer these questions, we must be more explicit. What do we mean 
by "human-centered automation"? Is it merely a catchy phrase, or a 
concept that can be defined and evaluated rigorously? 

• Because of the central importance of this question, we have given it 
considerable attention from the genesis of the Aviation Safety/Automation 
concept and program in 1987, though our work leading up to this program 
has been in progress for nearly a decade. 


HUMAN-CENTERED AUTOMATION PHILOSOPHY 
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+ INCREASING TREND OF AUTOMATION 




AIRCRAFT 



• What does the flight crew need to know? 

• The answer depends on the automation philosophy embodied in the aircraft: 

- Why is the flight crew informed? 

- What are they expected to do about the information? 

- Are they informed before, or after, action has been taken? 

- Are they expected to diagnose the problem, choose a course of action, 
concur with such a choice, carry out the action, or simply to be aware of 
altered aircraft configuration or status? 


* These and other similar questions about increasingly 
competent and autonomous automated systems have led to a 
search for a set of irreducible first principles for human- 
centered aircraft automation. 


• Our present construct is shown in the following viewgraph, in the 
hope that we shall receive constructive criticism from the experts 
at this workshop. 





HUMAN CENTERED AUTOMATION: FIRST PRINCIPLES 


PREMISE: The pilot bears the ultimate responsibility for the safety of 

any flight operation. 

AXIOM: The human operator must be in command . 

COROLLARIES: The human operator must be involved . To be involved, 

the human operator must be informed . 


Because systems are fallible, and in order to remain informed, 

The human operator must monitor the system. 

Because humans are likewise fallible, 

The system should also monitor the human operator. 

If monitoring is to be effective, 

Each component must have knowledge of the other's 
intent . 


HUMAN-CENTERED AUTOMATION: APPLICATIONS OF 

CONSTRUCT 


WeTiave examined a number of mishaps and proposed systems in terms of this 
construct: 

• China Airlines descent into SFO 

- Needed A/P status information not immediately obvious 

- Flight crew not sufficiently involved 

- Was system effectively in command? 

• Air Canada fuel exhaustion 

- FMC system knew flight crew intent 

- But aircraft was unable to inform crew of insufficient fuel 

• A proposed system with automatic reconfiguration 

- Should operator be informed of problem, or solution? 

- Should operator be involved in decision to reconfigure? 


HUMAN-CENTERED AUTOMATION PHILOSOPHY 


We have used this construct to evaluate a limited number of automated systems 
in current aircraft. 

• It points out certain known shortcomings in these systems, especially 
with respect to information management 

• It also suggests ways in which information transfer between humans and 
systems might be improved 


We are using this construct in the design of automated checklists for a series of 
experiments which will begin this fall 

• To determine whether the construct is viable 

• To determine how it must be modified or extended to serve as the basis 
for human-centered automation guidelines in our studies: 

- automated procedures monitoring 

- smart checklists 

- automated diagnostics systems 


SUMMARY 


• Objectives of this Element of the Program 

- Development of concepts and guidelines 

- Evaluation of competing philosophies 

- Integration of program elements in an intelligent, human-centered 
automated cockpit 

- Functional validation of these concepts and systems 

• Cooperative research with industry in pursuit of these goals 

• Hopefully, incorporation of validated concepts into automated interactive 
cockpit design tools. 


Why does the 747-400 have NASA-Developed 

WlNGLETS BUT NO NASA-DEVELOPED 

Take-Off Monitor? 



Or, Why is Technology Transfer harder in Flight Deck 
than in Aero, Structures, and Propulsion 


TECHNOLOGY TRANSFER 

OUTLINE 


• Goal 

• Who 

• What 

• How 


Preconditions 

Impediments 

Solutions 


TECHNOLOGY TRANSFER 


GOAL 


What is the most effective means for accomplishing 
the transfer of the program's research products? 


ORGANIZATIONAL FRAMEWORK FOR 
SUCCESSFUL TECHNOLOGY TRANSFER FROM 
NASA PROGRAMS TO COMMERCIAL TRANSPORT AIRCRAFT 
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Feedbock 
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TECHNOLOGY TRANSFER 


TO WHOM 

• Transport Aircraft Manufacturers 

• Business Aircraft Manufacturers 

• Avionics Manufacturers 

• Airlines 

• Pilots 

• Controllers 

• FAA (Standards, Regulations) 

• Research Community (Academic & Industrial 
Standards) 

• Military 

• NTSB 


AND FROM WHOM 


WHAT (OUTPUT) 

• Information (Tools, Measures) 

• Technology (Systems, Designs, Hardware) 

• Methods - Measures 

• Guidelines (Training, Operational Design) 

• Candidate Designs (Early Prototypes) 

• Technical Support 


eg 



TECHNOLOGY TRANSFER 


HOW (APPROACH) 

- Preconditions 

- Impediments 

- Solutions/Suggestions 


PRECOND1HONS/PROPER ENVIRONMENT 


• Clear Goal Statement (Shared Goals) 

• Economic Incentives 

• Measurement Technology 

• Ease of Interaction 


Stable Funding 


TECHNOLOGY TRANSFER 


IMPEDIMENTS 

• Poor Customer Interface 

• Geography 

• Human Factors Domain (Soft Science) 

• NAS Incompatibility 

• Type Rating Schemes 

• Measurement Techniques 

• Lack or Slandardizalion/Cross Feeding Simulation 

Scenarios Methodology 

• Foreign Competition 

• Proprietory Rights 

• Allocation of Resources 

• Limited Market Place 



102 



INDUSTRY NASA + INDUSTRY 


TECHNOLOGY TRANSFER 


SOLLTIONS/SUGGESTIONS 

• Living Program Plans 

• Workshops 

• Newsletters (Electronic, Multi-Media, 
Ilyper-Media) 

• Networking Technologies - Support Structure 

• Temporary Personnel Exchanges 

• Cooperative Teams 

• Consortium Contracts (Novel Contracting) 

• Portability/Compatibility 

• Methods and Scenarios 

• Hardware and Software 

• Demonstrations 
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Program End 



REALIZAflOTf OF SUCCESS 

1 . User/Peer Review 

• Demonstrations 

• Simulations 

2. Inclusion in Product Definitions 

3. Citation Frequency 


4. Implementation 

• FAA Certification 

• Training 

• ATC 

• Aircraft Design 


5. 


Improved Aviation Safety and Efficiency 



